Loadbalancing network traffic across multiple remote inspection devices

ABSTRACT

Methods of balancing network packet traffic among multiple checking functionalities (CFs) are described. A network has at least one client operatively connected to at least one source switch and multiple available CFs operatively connected to at least one destination switch. Each available CF has predetermined, but possibly different inspection capabilities. A source switch receiving packets from a client inspects each packet and can optionally choose an available CF having at least the minimum necessary inspection capabilities to inspect the particular packet, and tunnel the packet to the chosen CF.

BACKGROUND

Computing networks can include multiple network devices such as routers,switches, hubs, servers, desktop PCs, laptops, workstations, andperipheral devices, e.g., printers, facsimile devices, and scanners,networked together across a local area network (LAN) and/or wide areanetwork (WAN).

One advantage realized by networks is the ability to share networkresources among dispersed clients. For example, networks can includechecking functionalities, e.g., an intrusion system (IS), e.g.,intrusion prevention system (IPS) and/or intrusion detection system(IDS) that serve to detect unwanted intrusions/activities to thecomputer network, as well as remediation servers that store operatingsystem patches, virus definitions, etc. Unwanted networkintrusions/activities may take the form of attacks through computerviruses and/or hackers, misconfigured devices among others, trying toaccess the network. To this end, an IS can identify different types ofsuspicious network traffic and network device usage that can not bedetected by a conventional firewall. This includes network attacksagainst vulnerable services, data driven attacks on applications, hostbased attacks such as privilege escalation, denial of service attacks,port scans, unauthorized logins and access to sensitive files, viruses,Trojan horses, and worms, among others.

To increase robustness, a network can contain multiple IS's, each withdiffering capabilities. In such a case, it is advantageous to directtraffic that needs to be examined to the IS device that meets theminimum capabilities for the type of traffic being sent, the securitylevel assigned to both the sender and recipient of the traffic as wellas the load on the IS. By balancing traffic across the multiple IS's,overall checking efficiency is improved.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an embodiment of a computing device network.

FIG. 2 is a block diagram illustrating a portion of a network, such asshown in FIG. 1, having network devices which can implement embodimentsof the present invention.

FIG. 3 illustrates a portion of a network, such as shown in FIG. 1,including network devices suited to implement embodiments of the presentinvention.

FIG. 4 illustrates a checking functionality (CF) selection table thatincludes CF capabilities and characteristics per tunnel to whichidentified packets can be sent according to embodiments of the presentinvention.

FIG. 5A is a table illustrating possible classification of packets thatmay be sent to a CF, shown at a high level.

FIG. 5B is a table similar to FIG. 5A, illustrating examples of realaddresses, protocol and port numbers in an actual working environment.

FIG. 6 provides a flow chart illustrating the general operation ofembodiments of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention may include network devices,systems, and methods, including executable instructions and/or logic. Inone embodiment of the present invention, a method includes using logicon a first network device to select a checking functionality based on anumber of criteria. The method uses logic on the first network device toselect the checking functionality from a list of checkingfunctionalities. The checking functionality is selected for processingpackets identified by the first network device. Logic on the firstnetwork device is used to tunnel packets to a second network device thatis associated with the selected checking functionality. The secondnetwork device has a destination address different from an originaldestination address of identified packets. The second network devicesends the original packet to the selected CF, where it is examined forsecurity violations, viruses, etc., as appropriate.

FIG. 1 illustrates an embodiment of a computing device network 100. Asshown in FIG. 1, a number devices can be networked together in a LANand/or WAN via routers, hubs, switches and the like. As used herein a“network device” means a switch, router, hub, bridge, etc., e.g., adevice having processor and memory resources and connected to a network100, as the same will be understood by one of ordinary skill in the art.Although the term switch will often be used herein, those skilled in theart will realize that embodiments may be implemented with other networkdevices. As the reader will appreciate, the term network device can alsobe used to refer to servers, PCs, etc., as illustrated further below.

The example network of FIG. 1 illustrates a print server 110-1 andprinter 111 to handle print jobs for the network 100, a mail server110-2, a web server 110-3, a proxy server (firewall) 110-4, a databaseserver 110-5, an intranet server 110-6, an application server 110-7, afile server 110-8, and a remote access server 110-9. A server, databaseserver 110-5 for example, could serve as a Checking Functionality (CF)server, storing the list of available CFs for the network (where a CFcan be an IS, counting device, accounting device, remediation device,Access Point Controller etc.). The examples described here do notprovide an exhaustive list of servers or CFs that may be used in anetwork.

The embodiment of FIG. 1 further illustrates a network managementstation 112, e.g., a server, PC and/or workstation, a number of “fat”clients 114-1, . . . , 114-N which can also include PCs and workstationsand/or laptops, and a number of “thin” clients 115-1, . . . , 115-M. Asused herein a “thin client” can refer to a computing device thatperforms little or no application processing and functions more as aninput/output terminal. That is, in this example, a thin client generallyrelies on the application processing being performed on a servernetworked thereto. Additionally, a thin client can include a client in aserver/client relationship which has little or no storage, as the samewill be understood by one of ordinary skill in the art. In contrast, a“fat client” is generally equipped with processor and memory resources,to perform larger application processing and/or storage.

As used with respect to FIG. 1, the designators “N” and “M” indicatethat a number of fat or thin clients can be attached to the network 100.The number that N represents can be the same or different from thenumber represented by M. The embodiment of FIG. 1, illustrates that allof these example network devices can be connected to one another and/orto other networks using routers, 116-1, 116-2, 116-3, and 116-4, andhubs and/or switches 118-1, 118-2, 118-3, 118-4, and 118-5. As notedabove, such network devices can include a processor in communicationwith a memory and may include network chips having hardware logic, e.g.,in the form of application specific integrated circuits (ASICs),associated with the number of network ports. The term “network” as usedherein is not limited to the number, type, and/or configuration ofnetwork devices illustrated in FIG. 1

As one of ordinary skill in the art will appreciate, many of the networkdevices (e.g., switches 118-1, 118-2, 118-3, 118-4, 118-5 and/or hubscaninclude a processor in communication with a memory and will includenetwork chips having logic, e.g., application specific integratedcircuits (ASICs), and a number of network ports associated with suchlogic. By way of example and not by way of limitation, the networkmanagement station 112 includes a processor and memory. Embodiments ofthe various devices in the network are not limited to a number of ports,network chips and/or the type or size of processor or memory resources.

Additionally as the reader will appreciate, a number of mobile devices,e.g., wireless device 121, can connect to the network 100 via a wirelessair interface (e.g., 802.11) which can provide a signal link between themobile device 121 and an access point (AP) 119. The AP 119 serves asimilar role to the base station in a wireless network, as the same willbe known and understood by one of ordinary skill in the art. As shown inFIG. 1, the AP 119 can be linked to an access point controller (APC)123, as the same will be known and understood by one of ordinary skillin the art, which connects the AP 119 over a packet switched signallink, e.g. an Ethernet link, to other network devices, e.g., router116-1. In other topologies, the APC 123 need not be in the path betweenthe AP 119 and the rest of the network 100, i.e., the AP 119 may connectdirectly to router 116-1, and the APC 123 may connect to switch 118-2.Additionally, the AP 119 and APC 123 may be one and the same, or evenintegrated into one of the other network devices, e.g., router 116-1.

As one of ordinary skill in the art will appreciate, each network devicein the network 100 can be physically associated with a port of a switchto which it is connected. Information in the form of packets can bepassed through the network 100. Users physically connect to the networkthrough ports on the network 100. Data frames, or packets, can betransferred between network devices by means of a network device's,e.g., switch's, logic link control (LLC)/media access control (MAC)circuitry, or “engines”, as associated with ports on a network device. Anetwork switch forwards packets received from a transmitting networkdevice to a destination network device based on the header informationin received packets. A network device can also forward packets from agiven network to other networks through ports on one or more othernetwork devices. As the reader will appreciate an Ethernet network isdescribed herein. However, embodiments are not limited to use in anEthernet network, and may be equally well suited to other network types,e.g., asynchronous transfer mode (ATM) networks, etc.

As used herein, the term “network appliance” is used to mean an add-ondevice, e.g., “plug-in” or “application module,” to a network ascontrasted with a “network device”, e.g., router, switch, and/or hub,etc., which are sometimes considered more as “backbone” componentdevices to a network. As the reader will appreciate, a networkappliance, e.g., checking functionality 150-1 or 150-2 can includeprocessor and memory resources capable of storing and executinginstructions to perform a particular role or function. A networkappliance can also include one or more network chips, e.g., ASICs,having logic and a number of ports, as the same will be known andunderstood by one of ordinary skill in the art.

In the example network implementation of FIG. 1 a checking functionality(CF) 150-1 is shown in association with switch 118-3, and a CF, 150-2 isshown in association with switch 118-2. In certain embodiments, thechecking functionality performed by a network appliance, e.g. checkingfunctionality 150-1 or 150-2 can perform the role of an intrusionprevention system (IPS), as may be supplied by a third party vendor ofnetwork security devices. In certain embodiments, the checkingfunctionality 150-1 or 150-2 can perform the role of an intrusiondetection system (IDS), or another diagnostic device, accounting device,counting device, etc., as may be supplied by a third party vendor.

As used herein, a network can provide a communication system that linkstwo or more computers and peripheral devices, and allows users to accessresources on other computers and exchange messages with other users. Anetwork allows users to share resources on their own systems with othernetwork users and to access information on centrally located systems orsystems that are located at remote offices. It may provide connectionsto the Internet or to the networks of other organizations. Users mayinteract with network-enabled software applications to make a networkrequest, such as to get a file or print on a network printer.Applications may also communicate with network management software,which can interact with network hardware to transmit information betweendevices on the network.

FIG. 2 is a block diagram illustrating a portion 200 of a network, suchas shown in FIG. 1, having network devices 218-S1, 218-S2, . . . ,218-SM, and 218-D1, 218-D2, . . . , 218-DN, e.g., switches, which canimplement embodiments of the present invention.

Although reference is often made herein to switches, those skilled inthe art will realize that embodiments of the invention may beimplemented in other network devices. Examples of other network devicesinclude, but are not limited to, wireless and/or wired routers,switches, hubs, bridges, etc., e.g., intelligent network devices havingprocessor and memory resources.

The source, e.g., “first,” switches 218-S1, 218-S2, . . . , 218-SM areeach connected to a number of clients, 214-11, 214-12, . . . , 214-21, .. . , 214-M1, 214-M2. The switches 218-S1, 218-S2, . . . , 218-SM arealso connected to a network 202 such as network 100 shown in FIG. 1.Destination, e.g., “second,” switches 218-D1, 218-D2, . . . , 218-DN areeach connected to a checking functionality (CF) 250-1, 250-2, . . . ,250-N. The destination switches 218-D1, 218-D2, . . . , 218-DN are alsoconnected to the network 202 linking them to the source switches. Asused with respect to FIG. 2, the designators “N” and “M” illustrate thatvarious networks can have various numbers of clients and networkdevices, e.g., switches.

A client, such as client 214-11 could send network traffic, e.g.,packets, through switch 218-S1. As described in more detail inconnection with FIG. 3, switch 218-S1 can have logic to identify packetsfor tunneling to a checking functionality. In the embodiment illustratedin FIG. 2, logic on switch 218-S1 can select a checking functionality,e.g., 250-2, from a list, such as that illustrated in CF capabilitiestable 460 in FIG. 4. Once switch 218-S1 selects a checkingfunctionality, it encapsulates and tunnels all identified packets fromclient 214-11 through the network 202 to the network device, e.g.218-D2, that is associated with the selected checking functionality250-2.

When a network device, e.g., switch 218-D2 receives the packets tunneledfrom switch 218-S1, logic on the switch 218-D2 can decapsulate thepackets and forward them to a CF, e.g., 250-2 for processing. Methodsfor the creation and maintenance of tunnels between “first” switches,e.g. source switch 218-S1, and “second” switches, e.g. destinationswitch 218-D2, are described in detail in co-pending, commonly assignedU.S. patent application Ser. No. 11/827,742, entitled “TunnelConfiguration” and having at least one common inventor, filed Jul. 13,2007 and is specifically incorporated by reference herein.

As is illustrated in FIG. 2, a number of clients, e.g., 214-11 and214-12 can be connected to a given network device, e.g., switch 218-S1.Furthermore, a switch 218-S1 can tunnel packets from multiple clients,214-11 and 214-12, to one or more particular CFs, e.g. CF 250-1 that areselected (based upon criteria that will be hereinafter described) viaone or more second network devices, e.g., switch 218-D1.

A checking functionality can be performed by a network applianceseparate from a network device, e.g., CF 150-2 in FIG. 1. Alternatively,a network device, e.g., switch 218-D1 in FIG. 2 can have a checkingfunctionality integrated onboard the network device.

Although reference is made herein to a “first”, e.g., “source” networkdevice and a “second”, e.g., “destination” network device, eithernetwork device could perform the functions of source and destinationnetwork devices as described herein. The terms “first” or “source” and“second” or “destination” are used merely to aid in understanding thevarious functions of network devices as they perform operationsaccording to embodiments described herein.

As the reader will appreciate, a network device that is either connectedto a CF, or has a CF integrated onboard the network device, e.g. adestination network device, could also receive packets from a client andtunnel identified packets to a different network device. As statedabove, a given network device can perform the operations of either a“first” or “second” network device.

FIG. 3 illustrates a portion 300 of a network, e.g., network 100 shownin FIG. 1, including network devices, 318-1, 318-3, . . . 318-N suitedto implement embodiments of the present invention. Certain devices arereferred to as “source” network devices and other network devices arereferred to as “destination” network devices. As used herein, “source”network devices means network devices, e.g., 318-1, having portsconnected directly or indirectly to network clients, 314-1, . . . 314-M.The network clients can include servers, “fat” and “thin” clients,including mobile network clients connected through an APC, etc., asdiscussed above in connection with FIG. 1. As used herein, “destination”network devices means network devices, e.g., 318-3, which are associatedwith checking functionalities (CFs), e.g., CF 350. Destination networkdevices can be associated with an external CF, as shown at 350, or canhave a CF integrated onboard the network device, as shown at 380-3.

As described in connection with FIG. 1, the various network devices,318-1, 318-3, . . . 318-N, can include switches, routers, hubs, etc.(shown as switches in FIG. 3). Such network devices, 318-1, 318-3, . . .318-N, can include processor(s), and memory resources. The networkdevices, 318-1, 318-3, . . . 318-N, can similarly include a number ofnetwork chips, e.g., 340-1, 340-3, . . . , 340-N, including logiccircuitry (hardware) which can execute instructions and/or logic andeach network chip, 340-1, . . . , 340-N, can include a number of networkports, 320-1, . . . , 320-P, and 322-1, 322-2, to send and receivepackets (network traffic) throughout the network 302. As mentionedabove, the logic circuitry of the number of network chips, e.g., 340-1,. . . , 340-N, can be in the form of an application specific integratedcircuit (ASIC) and include logic to serve as a media access controller(MAC).

As shown in FIG. 3, a number of ports 320-1, . . . , 320-P can beincluded on a network chip 340-1, . . . , 340-N and have access to logiccircuitry associated with a network chip 340-1, . . . , 340-N and to theprocessor and memory. As used with respect to FIG. 3, the designators“N” and “P” are used to illustrate that various networks can have avarious number of network devices, various numbers of network clients,and various network devices in a network may support or contain avarious and/or different number of ports. Embodiments are not limited tothe example shown in FIG. 3.

As shown in the embodiment of FIG. 3, a CF 350 can be connected to anetwork device, e.g., 318-3, which may be a destination network device.The CF 350 could also be provided as part of one or more switches, e.g.,318-3 at 380-3. As shown in FIG. 3, the CF 350 can include processor 351and memory 352 resources capable of storing and executing instructionsto perform a particular role or function. The CF can also include one ormore chips (ASICs), e.g., 353, having logic and a number of ports, e.g.,354-1 and 354-2, as the same have been described above.

In various embodiments, the CF 350 is an intrusion prevention system(IPS), as may be supplied by a third party vendor of network securitydevices. In various embodiments, the CF 350 can be an intrusiondetections system (IDS), another diagnostic device, an accountingdevice, a counting device, an access device, etc., as may be supplied bya third party vendor. Additionally, a CF may be a remediation serverassociated with a remediation VLAN, as noted above. Embodiments are notlimited to the examples given here. Further, the various operations ofsuch devices will be recognized and understood by one of ordinary skillin the art.

In the embodiment of FIG. 3, a packet is received from a port, e.g.,320-1, on a network device, e.g., switch 318-1, from a network client,e.g., 314-1. According to various embodiments, logic on the switch318-1, e.g., logic associated with the hardware of the network chip340-1, can identify original packets, which are received from ordestined to a particular port, e.g., 320-1, on the device 318-1.

In various embodiments, the logic selects a CF, e.g., 350, from a list,390-1, 390-N, also tables 460 in FIG. 4A, of available CFs. The list ofavailable CFs can include the network addresses of the CFs. The networkaddresses can be internet protocol (IP) addresses, among others.

According to various embodiments, the identified packets are tunnelencapsulated to tunnel the identified packets to a second networkdevice, which may be a destination network device, e.g., switch (S3)318-3, having a location different (e.g., remote) from an original MACdestination address of the identified packets. That is, the identifiedpackets are sent via a tunnel (e.g., 321-1) to the second networkdevice, e.g., 318-3, rather than forwarding the selected packets totheir original MAC destination address. As the reader will appreciate,the tunnel may be a secure tunnel.

FIG. 4 illustrates a table 460 used to select a checking functionality(CF) to which identified packets should be sent according to embodimentsof the present invention. That is, table 460 is populated withinformation used by logic of the first network device, e.g. sourceswitch S-1 218-S1 from FIG. 2, to select a CF to which identifiedpackets should be sent, among other uses. The logic of the first networkdevice uses table 460 (e.g., 390-1) to determine which CF should beutilized for the type of service and CF capabilities that may berequired.

In some embodiments, the logic can select a CF from the list in theorder of the list such that it matches packets from a first client witha first CF, packets from a second client with a second CF, etc. Logic onthe network device cycles through the order, sequentially selecting a CFfor packets tunneled from successive clients. Once a CF has beenselected for a given client, all packets from that client that areselected for tunneling are tunneled to the same CF. A CF can functionmore effectively when all packets that are part of the same flow arechecked by the same CF.

In various embodiments, the logic can select a CF based on trafficlevels for each CF. Appropriate traffic levels for each CF can bedetermined based on the processing capacity of the CF, the networkdistance between a switch and the CF, how much traffic has already beenallocated to the CF, among other means. As used here, “network distance”takes into account more than just physical distance. Network distancecan also include link speeds and latency. For example, it can beadvantageous to use high bandwidth, low latency links, even if thephysical distance is longer.

In other embodiments, the logic can select a CF based additionally onthe client's credentials, the destination of the packet and the type oftraffic being carried in the packet. The embodiment illustrated here isnot intended to limit the types of selection criteria.

The table 460 includes column 461 “TUNNEL/CF NUMBER” for indicatingavailable checking functionalities and an associated tunnel number.Column 462 “DESTINATION SWITCH IP ADDRESS” indicates the destinationaddress of the network device associated with a given CF. Column 463indicates the CF capabilities. Column 464 “CF COST METRIC” indicates therelative cost of sending packets to each checking functionality. Column465 “TRANSMITTED PACKET/BYTE COUNT” indicates the numbers of packets andbytes, tunneled to each CF. Column 466 “SECURITY/AUTHENTICATIONINFORMATION” indicates security information which can be used togenerate authentication or encryption information for the tunneledtraffic according to one or more embodiments of the present invention.

In the embodiment illustrated in FIG. 4, Column 461 indicates that thereare at least three possible CFs available. By way of example, and not byway of limitation, tunnel number 0 may be associated with CF-1, e.g.,250-1 in FIG. 2. Tunnel number 1 may be associated with CF-2, e.g.,250-2 in FIG. 2. Tunnel number N may be associated with CF-N, e.g.,250-N in FIG. 2. However, the designator “N” is intended to representthat a number of different CFs may be available. In various embodiments,the number of available CFs may be fewer or greater than three. Theembodiment illustrated here is not intended to limit the number ofnetwork elements.

Column 462 indicates the IP addresses of second network devicesassociated with each CF. For example, IP-D1 may be associated with theIP address for destination switch D1 (218-D1) in FIG. 2. IP-D2 may beassociated with the IP address for destination switch D2 (218-D2) inFIG. 2. IP-DN may be associated with the IP address for destinationswitch DN (218-DN) in FIG. 2.

Column 463 basically maintains a list of the capabilities of each CF,which is really a list of which protocols or services it understands andcan inspect. For example, a CF may understand web traffic, emailtraffic, file transfer traffic, etc. and can so be listed as such. Othercharacteristics of interest may be the ability to perform advanced virusdetection, firewalling, etc. For example, a low-end CF may only be ableto implement simple Access Control List (ACL) policies, such as client Acan not talk to client B, client A can not access the web, etc. A morecomprehensive CF may have capabilities to inspect data to check forviruses, e.g. if client A is downloading email, a more advanced CF maybe able to inspect the email and scan it for viruses, etc. Theembodiment illustrated here is not intended to limit the types ofselection criteria possible.

Typically, the more advanced CF devices are, by their nature, moreexpensive. This is one of the motivations of this invention; by sendingtraffic for inspection to the appropriate CF (i.e., the CF that has theminimum capabilities associated with the level of checking that isdetermined necessary for the packet in question), efficiency isimproved, which requires fewer high-end CFs.

Column 464 indicates the relative cost of sending network traffic toeach checking functionality. In the example embodiment illustrated inFIG. 4, CF-1 has a cost metric of 3, CF-2 has a cost metric of 2, andCF-N has a cost metric of 1. This indicates that it is 3 times more“expensive” to send traffic to CF-1 than CF-3. In this context,“expensive” encompasses factors such as the performance capabilities ofthe CF, its buffering capabilities, the network distance to the CF, etc.Again, the embodiments illustrated here are not limited to theseexamples. Other methods of deriving cost metrics are possible and willbe understood and practiced by those of skill in the art according tothe present invention.

Column 465 indicates the number of packets and bytes, e.g., P0, b0,tunneled to each checking functionality. In this example embodiment, P0may be associated with the number of packets tunneled to CF-1, and b0may be associated with the number of bytes tunneled to the same checkingfunctionality. P1 may be associated with the number of packets tunneledto CF-2, and b1 may be associated with the number of bytes tunneled tothe same checking functionality. PN may be associated with the number ofpackets tunneled to CF-N, and bN may be associated with the number ofbytes tunneled to the same checking functionality. This information canbe used along with the CF cost metric as one method of determining towhich CF a particular client's traffic should be sent.

Column 466 indicates stored security and authentication information forone or more checking functionalities. For example, KeyS0 may beassociated with security information for CF-1. KeyS1 may be associatedwith security information for CF-2. KeySN may be associated withsecurity information for CF-N.

In some embodiments, the tunnels can be secure tunnels. For example, atunnel could include authentication to allow the destination networkdevice to check that a tunneled packet truly did come from the sourcenetwork device specified in the packet. Another example includes fullencryption, which would fully protect the packet being tunneled from anysnooping by others as it crosses the network.

In addition, there is no limitation on the number of tunnels that can bedirected to any single destination switch (or checking functionality)from a single source switch. For example, two or more tunnel numbers mayhave identical destination switch IP addresses 462 but differentsecurity/authentication information 465. This allows tunneled traffic tobe given different levels of security protection or sent via differentnetwork paths, for example.

Although the embodiments illustrated in FIG. 4 use switches as examplesof network devices, embodiments are not so limited. As will beappreciated by one of ordinary skill in the art, other network devicescan be used. Furthermore, the embodiments illustrated in FIG. 4, containexamples of information that can be stored in a CF capabilities table.The reader will appreciate that such a table could contain more or lessinformation than is present in FIG. 4. Embodiments are not limited tothe specific examples illustrated herein.

The characteristics of each CF are known ahead of time to the sourceswitch. To populate this CF capabilities table (FIG. 4), a systemadministrator could manually enter the capabilities into the sourceswitch, or in a more advanced scenario, there could be a higher levelprotocol running that allows the source switch to query the CF to findwhat its capabilities are. In this regard, there is a somewhat standardway of doing this: most networking devices maintain a “ManagementInformation Base”, or MIB, that contains much information about thedevice, possibly including a useful list of capabilities. Conversely,the CF could “push” its list of capabilities to each possible sourceswitch.

It is also necessary to classify packets as they are sent from a clientand arrive at the source switch, e.g., in FIG. 3, packets sent fromclient 314-1 that arrive at port 320-1 on source switch 318-1. Todetermine what type of data a packet is carrying, where it comes fromand where it's going to, switch 314-1 will have logic to parse thepacket and extract the pertinent information. Such parsing operationsare standard practice in any network switch/router, etc., and areordinarily used to determine where to forward the packet to. Forexample, a standard switch typically has logic to extract the MACDestination Address (MAC DA) and MAC Source Address (MAC SA) from thepacket, and will maintain forwarding tables to determine which port tosend the packet to (based on the MAC DA). Such a forwarding table ispopulated by “learn” operations, e.g., when client 314-1 sends a packet,its own address will be the MAC SA of the packet. If this address is notalready present in the forwarding table for switch 318-1, it will be“learned” and associated with port 320-1. Thus, when some other clientsends a packet to client 314-1 and it arrives at switch 318-1, theswitch knows to send the packet to port 320-1.

More advanced packet parsing can also be performed to extract otherinformation from the packet. For example, routers, which operate usinglayer 3 (or most commonly, IP) addresses will extract at least the IPDestination Address (IP DA) from the packet as this must be used againto determine where to send the packet for a route operation. Commonly,the IP Source Address is also extracted, often for use in securityfunctionality (e.g., Access Control Lists, or ACLs). The layer 4protocol (transport layer) is also important at this point, as it helpsto define the actual “service” that is associated with the packet. Themost common layer 4 protocols are Transfer Control Protocol (TCP) andUser Datagram Protocol (UDP), and these both contain source anddestination port numbers that are also associated with the service.These port numbers are service port numbers, and have nothing to do withthe physical ports on a switch, e.g., 320-1, etc.

The layer 5 protocol (application layer) can also be used to refine theservice associated with the packet. For TCP or UDP transport layer, thedestination port number indicates this service, e.g., if an IP packetcarrying a TCP header with a destination port of 80 is identified, it isknown that an attempt to connect to a web server using the HTTP protocolis being made. A similar analysis can also be applied to determine othertraffic types, e.g. email typically uses SMTP (TCP port 25) or POP3 (TCPport 110); telnet or ssh (secure shell) are used to remotely log in toanother machine on the network, and use TCP port 23 or 22; File TransferProtocol (FTP) is used to transfer files between two computers and usesTCP port 21 for the control traffic.

In addition to classifying the packet as described above, it is alsouseful to know the actual person sending the packet. For most corporatenetworks, a login process is required to allow a user to access to thenetwork. Thus when a user logs in, it is also necessary to validatetheir identity to the network so that the user is tied to the MAC (orIP) address of the client that the user is using, and potentially alsoincluding the higher level identifiers (L4 port numbers, etc.) This isimportant because a desktop machine may be used by several users atdifferent times, or even simultaneously, to connect to the network,e.g., an open-use area in a company, or an internet cafe. It istherefore not necessarily possible to tie a MAC or IP address, etc. to aperson without a login process. Additionally, IP addresses can bedynamically assigned at login—another reason for needing usercredentials. If a login process is not required, less differentiationbetween users can be achieved, and so they then all have to be treatedas somewhat suspect.

A final part of the process is to take the information obtained from theabove described operation, i.e., what person is sending what type ofdata, and who are they sending it to, and use this to pick one of the CFdevices from the CF capabilities table shown in FIG. 4. This can begenerally done using existing Access Control List (ACL) functionality,but with a modification to allow an ACL action to send a packet to a CF.

Typically, ACLs are used for security purposes to either permit (allow)or deny (prevent) connections based on the IP addresses, IP protocol andlayer 4 port numbers contained in the packet. For example, FIG. 5A showsa high-level ACL table with a number of entries. The IP_SA columnidentifies the IP address of the sender of the packet, i.e., really theuser (as per above discussion regarding the login process), the IP_DAcolumn identifies the packet destination (IP destination address), theservice column identifies the service being requested (which can alsoinclude the protocol, source_port and dest_port, etc.), and the CFdevice column indicates the CF device that packets matching this ACLentry should be processed by (if a CF device is selected).

The FIG. 5A table is shown at a high level; in reality the table wouldhave real IP addresses, protocol and port numbers, and an example ofthat is shown in FIG. 5B. In this table, the following is assumed: theclients IP address is 10.15.16.1 (i.e., this is the IP address of user“mark1”), the mail server is 10.15.1.1, the print server is 10.15.2.1,the internal web server is 10.15.3.1 and the remote accounting server is10.16.1.1. In addition, all addresses from 10.15.0.0 to 10.15.255.255(i.e., 10.15.0.0/16) are considered “local”, all addresses from10.16.0.0 to 10.16.255.255 (i.e., 10.16.0.0/16) are considered “remote”,and all other IP addresses are considered external. For suchassumptions, FIG. 5B follows.

This extended ACL table is generally set up by software running on thelogic circuitry 340-1 of the source switch 318-1, although it could bedone equally as well using dedicated hardware on 340-1. The initialpolicies can be determined by a network administrator, e.g., the aboveFIG. 5B table could be the set of policies attached to user mark1 andstored by software. Once the source switch 318-1 detects a login by usermark1, this set of policies is loaded into the extended ACL table. Notehere that all of the src_port values are initially “X”, i.e., don'tcare, and some of the ip_da fields cover a large range of destinations(e.g., line 4 has 10.15.0.0/16, which really means 10.15.X.X and coversthe address range 10.15.0.0 to 10.15.255.255, which is 64 k addresses,as is readily known to those skilled in the art).

There is a subtle difference here for how the CFs are specified in theFIG. 5B table. If an entry in the table can cover a range of addresses(e.g., entries 5, 6, 8 and 11) that need to be processed by a CF, thenthe action is CFX-COPY. This indicates that the packet needs to becopied to software to make a determination as to which CF to truly use.This is described below. Also, it is not a requirement to specify thisCFX-COPY action for a range of addresses—for example, on entry 8, wecould just specify this as “CF3” such that all HTTP connections fromuser mark1 to any external web server go to CF3.

For entries marked as CFX-COPY, they are refined as actual connectionsare made, as follows: as a client opens up connections to a number ofdestinations, new entries will be added to the table where the trafficis being directed to a CF. For example, if mark1 sends a packet thatmatches entry 8 (accessing an external web server), and the ip_da is15.100.1.1, then we would see a new entry 8a added to the table abovethe original entry 8—

8a 10.15.16.1/32 15.100.1.1/32 6 9000 80 CF3

In this case, this connection has been assigned to CF3, but it could beany of the CFs that have the capabilities to process web traffic. Also,the src_port has now also been assigned a value (9000 in this case), butthis value is somewhat arbitrary—it will be read from the src_port fieldof the TCP header of the packet. How the client picks the src_portnumber depends on the Operating System and network stack, and is notrelevant for the purposes of this discussion. All this value does is toallow a client to open multiple connections to the same IP_DA andservice (ip_protocol and dst_port), with the connections beingdistinguished by different src_port values, as is known by those skilledin the networking art.

Again, assume that mark1 opens up another web connection to a differentserver, e.g., ip_da is 15.100.10.10, then we may assign this connectionto CF2 and thus would create another entry:

8b 10.15.16.1/32 15.100.10.10/32 6 9001 80 CF2 The ordering of theseentries is important - 8a 10.15.16.1/32 15.100.1.1/32 6 9000 80 CF3 8b10.15.16.1/32 15.100.10.10/32 6 9001 80 CF2 8 10.15.16.1/32  0.0.0.0/0 6X 80 CF3-COPY

Inasmuch as entries 8a and 8b are more specific than 8 (i.e., theyspecify an exact destination address as opposed to a range), they mustappear in the ACL table before entry 8 (if they did not, they wouldnever be matched against). The ACL table is really a list of entriesthat is compared against, and the first match that is found generatesthe result, which is why we have the ordering requirement of mostspecific matches first.

To determine which CF to send traffic to when a new connection is openedup, software running on the logic circuitry 340-1 of the source switch318-1 will determine the type of connection that is being attempted(e.g., http access to external_web_server), and compare this with thecapabilities of each CF stored in the CF capabilities column (463) oftable 460 of FIG. 4. This operation will generate a list of capable CFs,and from this one can be chosen based on an algorithm using the CF costmetrics (464) and the perceived load placed on the CF by this sourceswitch (derived from the transmitted packet/byte counts, 465). Ingeneral it is preferable to pick the CF with the lowest cost metric thathas the lowest load, although any algorithm could be developed and otherparameters could also be introduced. For example, a simple algorithmwould be to generate an estimate of the load on the CF by using thepacket counter to calculate the number of packets sent to the CF in,say, the last second (i.e., a packet rate). If this is then divided bythe maximum load that the CF can process (which can be a part of the CFcapabilities, and may be static or dynamic, allowing the CF to indicateits loading by other source switches), an approximate “load factor” onthe CF from the source switch is obtained. If the load factor is thenmultiplied by the CF cost metric, a cost-busyness value is obtained.Higher values indicate less desirable CFs (i.e., the CF is either busy,expensive to use, or a combination of both of these), and so picking theCF with the lowest value would be one method of choosing a CF.

Other algorithms are also feasible, and it is also possible for theadministrator to override any algorithm for specific traffic types,e.g., always send all web traffic destined to external web servers toCF3. Such an override permits specific company security policies to beenforced.

The above operation is also set forth in the form of a flow chart shownin FIG. 6, which is not independently described, because it is largelyself explanatory.

It should also be understood that most connections are actuallybi-directional, e.g., if a request for data is made, the response is thedata. Typically, an advanced CF may need to see the data in bothdirections so it can make a better determination as to the securityrisk, etc., of the operation being performed. The simplest way to dothis is for the source switch to also program an ACL entry for thereturn data when it programs the initial entry for a new connection. Forexample, from the discussion above, when we add entry 8a (shown againhere)

8a 10.15.16.1/32 15.100.1.1/32 6 9000 80 CF3to the ACL table, another entry 8aR for the return data from the servercan also be set up, as indicated:

8aR 15.100.1.1/32 10.15.16.1/32 6 80 9000 CF3

One problem with the above is that it is desired to enforce securitychecks on the edge of the network, and so the original source switch forthe client may not be the correct place to do the inspection for theresponse packets. For example, and referring to FIG. 1, if it is assumedthat client 114-1 is the client under discussion above, then switch118-1 would be the source switch for this client. However, if the clientis communicating with an external web server, the return traffic fromthis server would likely arrive from the internet 120, and in this casethe first switch (it is actually a router in this case, but that isimmaterial) is 116-2. Thus, for the return traffic, the source switch isnow really 116-2.

The problem here is when a client first starts a new connection and anACL entry is added (e.g., entry 8a above) to the first source switch(118-1 in FIG. 1), what is really needed is to determine the sourceswitch for the return data (this will be switch 116-2 in this case) andinform this switch that it needs to add an ACL entry to its table forthe return data (i.e., it would need to add entry 8aR to its ACL table,and this entry would not be added to switch 118-1).

In effect, it is desirable to apply a “network policy” to ensure thatthe return data goes to the same CF. Rather than trying to determine thesource switch for the return data and notifying it to add an ACL entryto its table, as described above, it is more robust to have the completenetwork know about the checking policies applied. In this case, theinformation presented in the table of FIG. 5B would be known to allswitches (or strictly, all “edge” switches) in the network. Referring toFIG. 1, all of the switches 118-1 to 118-5 have clients or serversattached, and so are edge switches, as are routers 116-1, 116-2 and116-3 (these have connections to wireless clients (116-1), or toexternal links (116-2 and 116-3)). Note, however, that router 116-4would not be considered an edge device in this case, as it only connectsto other network switches or routers, and not to any clients. Thus, whena client sends a packet for a new connection, an ACL entry will be addedto the source switch (i.e., add entry 8a to source switch 118-1 forclient 114-1). When the packet, that in this case is destined for theinternet 120, arrives at switch (router) 116-2, this switch willrecognise that it is the “edge” switch for this packet as it leaves thenetwork, and so will also be the edge switch for the return packet fromthe external web server (in this example). Thus, switch 116-2 will addentry 8aR to its ACL table, in preparation for the return data from theweb server. Alternatively, all edge switches could be informed of thereturn entry 8aR (but not program it into their tables until they see areturn packet), since in some network topologies the return path is notthe same as the forward path.

It is to be understood that the above description has been made in anillustrative fashion, and not a restrictive one. Although specificembodiments have been illustrated and described herein, those ofordinary skill in the art will appreciate that other componentarrangements and device logic can be substituted for the specificembodiments shown. The claims are intended to cover such adaptations orvariations of embodiments of the present invention, except to the extentlimited by the prior art.

In the foregoing Detailed Description, various features are groupedtogether in a single embodiment for the purpose of streamlining thedisclosure. This method of description is not to be interpreted asreflecting an intention that any claim requires more features than areexpressly recited in the claim. Rather, as the following claims reflect,inventive subject matter lies in less than all features of a singledisclosed embodiment. Thus, the following claims are hereby incorporatedinto the Detailed Description, with each claim standing on its own as aseparate embodiment of the invention.

1. A method of balancing network packet traffic among multiple checkingfunctionalities (CF) in a network having at least one source switchoperatively connected to at least one client and multiple available CFsoperatively connected to at least one destination switch, wherein eachavailable CF has predetermined, but possibly different inspectioncapabilities, comprising the steps of: processing a particular packetfor inspection on a source switch; forwarding the particular packet toan available CF having at least the minimum necessary inspectioncapabilities to inspect the particular packet.
 2. A method as defined inclaim 1 wherein said forwarding step further comprises: determining thecharacteristics of the client from which the particular packetoriginated; determining the type of the particular packet; determiningthe characteristics of the available CFs; selecting a CF that has thenecessary characteristics to inspect the particular packet; and sendingthe particular packet to the selected CF.
 3. A method as defined inclaim 2 wherein said step of selecting a CF that has the necessarycharacteristics further comprises selecting a CF that has the minimumcharacteristics necessary to inspect the particular packet.
 4. A methodas defined in claim 2 wherein the type of the particular packet is basedupon criteria selected from the group consisting of: a physical ingressport that the packet arrived on; a source MAC address of the packet; adestination MAC address of the packet; a source IP address of thepacket; a destination IP address of the packet; an IP protocol field ofthe packet; a TCP or UDP source port of the packet; a TCP or UDPdestination port of the packet; and a Priority or DifferentiatedServices Code Point of the packet.
 5. A method as defined in claim 2wherein the characteristics of the client are based upon criteriaselected from the group consisting of: the type of security the clienthas; the level of security of the client; the location of the client;whether the client is a mobile client; whether the client is a fixedclient; the identity of a user logged in to the client; and the securityclearance of a user logged in to the client.
 6. A method as defined inclaim 5 wherein the location of the client is based upon criteriaselected from the group consisting of: a public area; an office area;and a secure area.
 7. A method as defined in claim 2 wherein thecharacteristics of the CFs include their packet inspection capabilityand speed of operation.
 8. A method as defined in claim 7 wherein thepacket inspection capability and speed of operation is based uponcriteria selected from the group consisting of: the types of datastreams that the CF can inspect; whether the CF can analyze foranomalies; the buffer capacity of the CF; and the packet processingspeed of the CF.
 9. A method as defined in claim 8 wherein the types ofdata streams comprise one or more of the following: UDP; TCP; HTTP; POP;FTP; and NFS.
 10. A method as defined in claim 1 wherein said forwardingstep is carried out by a source switch which also determines anavailable CF, said source switch monitoring the packet traffic that itis sending to a first available CF and having the capability ofpreemptively forwarding a packet to another available CF if it isalready sending a large amount of traffic to said first available CF.11. A method as defined in claim 1 wherein a source switch forwards thepacket using a secure tunnel to an available CF without modifyingrouting tables in the network.
 12. A method as defined in claim 1wherein each CF is one of an Intrusion Detection System or an IntrusionPrevention System.
 13. A method as defined in claim 1 furthercomprising, once a CF has been selected to receive a particular packet,forwarding all packets selected for inspection from a same client asthat particular packet to the same CF.
 14. A method as defined in claim1 further comprising selecting said available CF based on relativetraffic levels as a group of CFs having at least the inspectioncapabilities to inspect the particular packet.
 15. A method as definedin claim 1, further comprising forming two or more different tunnelswith different security mechanisms between said source switch and saidavailable CF.
 16. A method as defined in claim 1, further comprisingforming two or more different tunnels with different security mechanismsbetween said source switch and a number of said CFs.
 17. A method ofoptimizing checking functionality (CF) resources in a computer networkhaving a plurality of CFs attached to at least one destination switch,at least one source switch attached to at least one client, and saidplurality of CFs have differing packet inspection capabilities rangingfrom high to low, said method comprising: selecting packets from asource switch for inspection; forwarding the selected packets to aparticular available CF having at least the minimum necessary inspectioncapabilities to inspect the particular packet, said particular availableCF being determined based upon the characteristics of the client anduser from which the particular packet originated, the type of theparticular packet and the characteristics of the particular availableCF.
 18. A network comprising: multiple checking functionalities (CF)individually attached to individual destination switches, said multipleCFs including CFs with differing packet inspection capabilities rangingfrom high to low; at least one source switch attached to at least oneclient; said at least one source switch being configured to processpackets for inspection by a CF, said source switch determiningcharacteristics of the client originating the packets, determiningcharacteristics of the packet, determining characteristics of the CFsand forwarding selected packets to an acceptable available CF to performthe inspection, wherein the acceptable available CF has a lower butsufficient packet inspection capability to perform the inspection.